Enterprise messaging systems enable computer programs to exchange information. These applications may be distributed among various computers located within a particular physical location, or distributed across an enterprise computer network at disparate physical locations. These computers may be coupled through a Large Area Network (LAN), a Wide Area Network (WAN), etc. The enterprise messaging systems that enable such communication, such as Microsoft's Message Queuing (MSMQ) assume that senders and receivers are symmetrical in their messaging capabilities, and that there is seamless direct connectivity between the sending and the receiving applications. Such communication utilizes a peer-to-peer communication model that allows either peer to generate and transmit messages to the other peer.
As computer networks expand, and as business-to-business (B2B) e-commerce continues to grow, the need for messaging between computers located on separate private networks across the Internet becomes more and more important. Unfortunately, many private computer networks are protected from the public Internet by a firewall or proxy system. Typically, web proxies mandate the use of the Hyper-Text Transfer Protocol (HTTP) as an enabling protocol on top of which higher-level protocols may be built. Because web proxies mandate the use of HTTP as enabling protocol, they create a setting in which the sender and receiver do not have the same, or symmetrical, capabilities. Specifically, in the HTTP protocol environment, the Internet-deployed party cannot directly, and without assistance, send messages to the party within the corporate firewall. As a result, this changes the communication model from a peer-to-peer communication model to a client-server communication model. As such, the “server” is unable to communicate directly with the “client” unless and until the “client” has initiated a communication session through the web proxy or firewall. With this limitation on the client-server communication model dictated by the HTTP protocol, true peer-to-peer messaging is no longer possible.
By design, HTTP is a request-response protocol in which data exchanges are initiated by a web client. This is true for both direct client-to-server connections as well as for indirect connections facilitated by a web proxy server. HTTP requires that the web client send a request to the web server, and that the web server reply to the client. When a web proxy is utilized to isolate the public Internet from the private intranet or other private computer network, HTTP requires that the client send a request to the web proxy, which then forwards the request to the web server. In reply, the web server sends the web proxy a response to this forwarded request. It is then the web proxy that relays this server response to the client. Because of this web proxy limitation mandating the use of HTTP, communication protocols built on top of HTTP do not allow a web server to send unsolicited data to a client. In this context, unsolicited refers to data that is not sent as a reply to a client's request for information.
One system that has been devised to overcome the HTTP client-server model communications problem for messaging is known as polling. Under this polling system, the “client” processor periodically and frequently sends out an HTTP request for messages as illustrated in the timeline of FIG. 5. As may be seen from this timeline, the client processor periodically transmits message requests 101, 103, 105, 107, etc. to the server. The frequency at which these messages are sent from the “client” to the “server” is dependent upon the application's data processing needs, and is often within the realm of once per second. Unfortunately, this polling technique greatly increases network traffic, especially in situations where the “server” has no messages to be sent to the “client”. For each polling request that results in the delivery of a message in a polling reliable messaging system, 101, 103, 105, 107, etc., the HTTP-governed three-way handshake is conducted. That is, for each information poll request sent by the “client” to the “server”, a response must be generated by the “server” providing the message as an acknowledgement of the information request, which in turn must be followed by an acknowledgement back from the “client” to complete the three-way handshake procedure governed by HTTP. If there is no message waiting, the server can simply reply with a “no messages waiting” response. The server does not need to wait for the client to confirm the receipt of this message because it does not require any state change in the server. A further disadvantage of this type of system exists since no information is capable of being sent from the “server” to the “client” unless and until the polling request message is received. During periods of heavy activity, the server may generate a significant number of messages. These messages must be queued until the next opportunity to transmit to the “client” in response to the next poll request. As may well be imagined, this may significantly delay the processing in both the “client” and the “server” processor, and may result in time-critical messages not being sent on time.
A protocol that does allow for a “server-push” model of communication whereby the server may provide unsolicited data to a client residing on the private side of a web proxy is known as the Real Time Trading Protocol (RTTP). This protocol is utilized to provide real-time stock quotes and other real-time financial information over the Internet. However, the RTTP protocol does not provide for bi-directional communication between the client and server, but instead merely provides updated information for display at the client location. RTTP utilizes a technology known as smart tunneling and secure tunneling to penetrate the network web proxy firewall. RTTP may tunnel through a web proxy because the type of information transmitted is lightweight and can be wrapped within HTTP packets when appropriate. While such may not present a security concern for some networks, many sophisticated corporate firewalls and web proxies may not allow for such tunneling.
In view of the above, there exists a need for a reliable bi-directional HTTP-based message system that will allow distributed computers on opposite sides of web proxies to communicate in a virtual peer-to-peer relationship.